|
|
|
|
|
|
0495239
|
00135.201971/2017-04
|
|
|
MINISTÉRIO DOS DIREITOS HUMANOS
ANEXO I - PROCESSO DE ENTREGA DE SOLUÇÕES - PES
I - Visão dos Eixos
1 - Estruturação
O eixo Estruturação trata dos temas relacionados ao planejamento dos projetos, à atualização e divulgação do Processo de Entrega de Soluções (PES), à identificação de requisitos, à atualização e divulgação da arquitetura de referência do MDH e à qualidade.
2 - Engenharia
O eixo Engenharia trata dos temas relacionados ao desenvolvimento ou de produção do software, bem como a utilização do Processo de Entrega de Soluções (PES) que inclui todas as atividades que tem por objetivo a elaboração de requisitos, a arquitetura de software e desenho, a interface gráfica, implementação e a verificação e validação do software, sempre mantendo a qualidade desejada por este Ministério.
3 - Entrega
O eixo Entrega trata dos temas relacionados à entrega do software confiável, previsível, com riscos quantificáveis e bem entendido.
Utiliza o Processo de Entrega de Soluções (PES) e inclui todas as atividades de preparação de serviços de TI, gestão da configuração, conteinerização das aplicações, execução de testes automatizados, testes não-funcionais, scripts de provisionamento e sincronização de ambientes.
4 - Sustentação
O eixo Sustentação trata dos temas relacionados à sustentação do software, garantindo que, quando for preciso fazer alguma modificação, o tempo para realizá-la e colocá-la em produção e em uso, seja o menor possível e que problemas sejam encontrados cedo o bastante para que sejam fáceis de corrigir. Utiliza o Processo de Entrega de Soluções (PES) e inclui todas as atividades para a sustentação do software.
II - Visão das Fases
1 - Iniciação
A Iniciação é a primeira fase de uma release, dura normalmente uma sprint e consiste de:
- Revisão e priorização do Backlog da Release;
- Definição do objetivo dos Épicos, Features e Histórias de Usuário já identificadas;
- Refinamento do Backlog;
- Estimativa dos Épicos, Features e Histórias de Usuário já identificadas a fim de obter a estimativa total da release em termos de pontos de história;
- Definição (ou revisão, caso já exista) da arquitetura da solução;
- Definição da estratégia de testes;
- Definição dos ambientes necessários; e
- Estimativa da velocidade do time.
As cerimônias do PES também são aplicáveis à(s) sprint(s) da fase de Iniciação (ver 2 - Construção)
2 - Construção
Na fase de Construção são realizadas as sprints em que as histórias de usuário são preparadas, construídas e testadas.
Importantes cerimônias do processo ágil ocorrem durante as sprints:
2.1 Planejamento da Sprint
A reunião de Planejamento da Sprint é composta de duas fases: planejamentos tático e operacional.
2.1.1 Planejamento Tático
Nesta fase, o Dono do Produto apresenta os objetivos da sprint e as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas, após a reunião, na fase chamada de Planejamento Operacional.
Para cada item do Backlog da Sprint, é necessário obter do Dono do Produto a definição de pronto do item, assim não há dúvidas na hora de receber o produto previsto no item de trabalho planejado. Além disso, para cada item do Backlog, o Líder de Projeto (que
é o responsável pelo planejamento) deve associar a release do Produto à qual o Projeto está vinculado (com isso, o gráfico de Burnup é gerado automaticamente).
No campo Descrição do item de backlog, deve-se incluir uma pequena descrição do item e a definição de pronto do item (o critério que será usado para aceitar o item ao final da sprint). É importante que essa definição leve em conta as descrições de produto pronto e de item preparado do PES (ver item 2.1.2 a seguir) e a visão do Dono do Produto, pois ele é quem aceita ou recusa as entregas da sprint, e que seja um critério facilmente verificável durante a reunião de encerramento da sprint. A emissão do Termo de Aceitação da Sprint deve ser realizada imediatamente após a reunião de encerramento e depende grandemente da definição objetiva da descrição e da definição de pronto.
2.1.2 Planejamento Operacional
Nesta fase, a equipe se encontra separadamente para conversar sobre o que ela escutou, decidir com quanto ela pode se comprometer a fazer na Sprint e quebrar as funcionalidades em tarefas. Em alguns casos, haverá negociação com o Dono do Produto, mas será sempre responsabilidade da equipe determinar com quanto ela será capaz de se comprometer.
É muito importante que os itens de backlog priorizados já tenham sido preparados antes da reunião. Itens que chegam à reunião sem detalhes suficientes podem colocar toda a sprint em risco.
Definição de produto preparado:
- Trabalhado em sessões de Refinamento do Backlog;
- Estimado;
- Pequeno o suficiente (idealmente, estimativa não superior a 8 pontos de história); e
- Com critérios de aceitação (apresentados como cenários) definidos.
Definição de produto pronto: definição expressa por meio de funcionalidades desenvolvidas em cada Sprint com 100% de completude, demonstrado por:
- Atendimento aos critérios de aceitação (apresentados como cenários) da história de usuário;
- Código completo;
- Testes unitários escritos e executados com sucesso (conforme cobertura dos testes definida na OS);
- Teste de integração executado com sucesso;
- Documentação escrita; e
- Aprovação do dono do produto.
2.2 Refinamento do Backlog
A equipe (ou parte da equipe, incluindo o dono do produto) se reúne regularmente, em uma reunião formal ou informal, para refinar o Backlog da Release com o objetivo de:
- decompor épicos e features;
- preparar histórias de usuário;
- dividir histórias de usuário priorizadas para caber em uma sprint;
- realizar a estimativa de histórias que ainda não a possuem;
- revisar as estimativas de histórias em função de informações recém-descobertas;
- remover histórias de usuários que não são mais relevantes; e
- criar novas histórias de usuários em resposta às necessidades recém-descobertas reavaliar a prioridade relativa de histórias.
2.3 Encerramento da Sprint
O encerramento da sprint é realizado também em duas fases: a revisão e a retrospectiva.
2.3.1 Revisão da Sprint
Ao final de cada Sprint é realizada a reunião de Revisão da Sprint, em que a equipe mostra o que foi alcançado durante a Sprint, no formato de uma demonstração das novas funcionalidades, e uma breve apresentação das ocorrências importantes da Sprint.
Durante a Revisão, o projeto é avaliado em relação aos objetivos da Sprint, determinados durante a reunião de Planejamento da Sprint.
2.3.2 Retrospectiva da Sprint
A reunião de Retrospectiva da Sprint ocorre ao final de uma Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar.
3 - Transição
A Transição é a última fase de uma release, dura normalmente duas sprints e consiste de:
- Garantir que a solução é estável o suficiente para a publicação em produção;
- Realizar testes independentes não funcionais na solução final;
- Corrigir defeitos encontrados nos testes independentes;
- Treinar usuários no uso da solução;
- Finalizar e publicar manuais necessários à utilização da solução; e
- Publicar a solução de software em ambiente estável. Idealmente, a transição deveria ser a instalação da solução em ambiente de produção. Entretanto, como depende do planejamento das evoluções do produto, é mais comum ser em ambiente de homologação controlado.
As cerimônias do PES também são aplicáveis às sprints da fase de Transição (ver 2 - Construção)
4 - Operação
A Operação é a fase em que a solução está funcional em ambiente de produção.
Arquivos
Grafico_de_Baleia_PES_v2.jpg 109 KB 28/12/2016 Clara Barbosa
PES_INICIACAO_DA_RELEASE.jpg 122 KB 28/12/2016 Clara Barbosa
PES_SPRINT_DE_TRANSICAO.jpg 133 KB 28/12/2016 Clara Barbosa
PES_SPRINT_DE_CONSTRUCAO.jpg 195 KB 28/12/2016 Clara Barbosa
Referência Bibliografica
Acessado em 26/04/2018 no link: http://www.planejamento.gov.br/acesso-a-informacao/licitacoes-e-contratos/licitacoes/pregao/2018/pregao-eletronico-por-srp-no-02-2018
Este processo foi baseado no modelo referencia publicado pelo Ministério Planejamento sobe o nome de Processo de Entrega de Solução - PES
 | Documento assinado eletronicamente por Leandro de Castro Abelha, Chefe de Serviço de Gestão de Contratos, em 15/06/2018, às 09:21, conforme o § 1º do art. 6º e art. 10 do Decreto nº 8.539/2015. |
| | Documento assinado eletronicamente por Edimar Dantas Nobrega, Chefe de Divisão de Desenvolvimento e Engenharia de Sistemas, em 15/06/2018, às 11:56, conforme o § 1º do art. 6º e art. 10 do Decreto nº 8.539/2015. |
| | Documento assinado eletronicamente por Davi Vernon Carlos de Oliveira, Coordenador(a) Geral de Tecnologia da Informação, em 15/06/2018, às 12:10, conforme o § 1º do art. 6º e art. 10 do Decreto nº 8.539/2015. |
Referência: Processo nº 00135.201971/2017-04
|
SEI nº 0495239
|
